\chapter*{Maya + Renderman = хорошо}
  

  Теперь, когда мы достаточно поверхностно (а я вас предупреждал!) рассмотрели теоретические основы подключения внешних рендереров к Maya, пришло время обратить
  внимание на практический пример, в качестве которого у нас с вами выступит связка Maya и Photorealistic Renderman, а именно конкретная реализация такой связки –
  продукт под названием MTOR.
  

 Почему мы с вами собираемся рассматривать именно эту связку?

В последнее время стал очевиден тот факт, что такой симбиоз продуктов – использование Photorealistic Renderman в качестве рендерера для Maya - стал стандартом де-факто
в индустрии визуальных эффектов; в особенности это касается визуальных эффектов для кино. Почему это именно так и почему считается, что такая связка является
стандартной - мы узнаем чуть позже, а пока сделаем некоторое отступление, глубокий вдох и остановимся на том, что такое Photorealistic Renderman и что такое Renderman
как понятие.
  

 Я, думаю, что вы уже обратили внимание на этот факт, как я легко и непринуждённо разделил две эти вещи. Такое разделение имеет под
    собой достаточно серьёзные основания.
  

 В свое время, когда мы (группа единомышленников, объединившаяся в рамках сообшества Renderman.ru) только начали заниматься Renderman и пропагандой этого стандарта в
русскоязычном интернете, приходилось достаточно часто сталкиваться с обращением новичков «Где скачать Renderman для Maya?». Я лично, будучи модератором посвященных
Renderman форумов, потратил многие часы своей жизни ответу на этот вопрос и его широко распространённую разновидность – Где Скачать Renderman для Макса? (Как показал
опыт, данное упражнение развивает как мышцы пальцев, так и любовь и терпимость к окружающим).

Оставив в стороне правовые стороны такой постановки вопроса (а именно ту его часть, которая “где скачать”), остановимся на том, что в его основе лежит широко
распространённое заблуждение.

Как оказалось, достаточно просто перепутать два понятия - понятие Renderman как стандарта и понятие Photorealistic Renderman (prman) как продукта, реализующего этот
стандарт. И основной причиной этой путаницы является cама компания Pixar, которая сначала создала стандарт Renderman, а потом начала распространение собственного
продукта с очень похожим именем. И что самое смешное, эта компания продолжает подливать масла в огонь беспорядку в наименовании, подготавливая к выпуску продукт,
который называется – Renderman for Maya! (Для окончательного запутывания народа Pixar’у осталось анонсировать Renderman for 3dsmax)
  
Что же  такое Renderman? 

Renderman - это стандарт описания трехмерных данных для их последующей визуализации. В сборнике часто встречающихся вопросов и ответов ньюсгруппы
comp.graphics.rendering.renderman написано так: “Renderman - это стандартный интерфейс между программами моделирования и рендеринга для создания качественного
фотореалистического изображения”. Работая над стандартом Renderman (а работа эта началась в доисторические времена - в 1987 году), компания Pixar поставила перед собой
достаточно амбициозную цель - пытаясь воспользоваться идеями формата файлов Postscript как некоей среды для обмена векторными двухмерными данными (а к тому моменту
Postscript был уже широко развит и использовался повсеместно), сделать аналогичный шаг и создать новый универсальный формат для обмена информацией между системами для
моделирования и анимации и системами для рендеринга, который был бы достаточно универсален для того, чтобы занять место Postscript в мире трехмерных приложений.
  

Основной особенностью стандарта Renderman является тот факт, что данный стандарт разделяет понятия геометрии в сцене и материала, который накладывается на данную
геометрию. Параметры и строение сцены описываются посредством Renderman Interface. В первоначальном варианте спецификации стандарта Renderman Interface являлся
интерфейсом для языка программирования C, с использованием которого вы могли написать программу, которая бы вызывала рендерер и передавала ему необходимые параметры.
Чтобы отрендерить прямоугольник, вам было необходимо написать приблизительно такую программу (текст программы адаптирован из книги RenderMan Companion):
  
\code{code/test.c}  

 Ничего особо страшного, но и приятного для человека
    с непрограммистским складом ума – тоже маловато. В качестве
    дополнительной возможности первой спецификации значился экспорт
    данных в промежуточный формат данных под названием RIB,
    что расшифровывается как Renderman Interface Bytestream. Вот
    так вот будет выглядеть та же самая сцена в этом формате (я получил
    её, окомпилировав приведенный выше код на С в исполняемый файл и
    запустив полученную программу):

\code{code/ex1.rib}  

 Ваша интуиция вас не подводит - впоследствии
    оказалось,  что в
    большинстве случаев гораздо удобнее работать именно с
    форматом RIB, который и
    стал основной частью Renderman Interface, хотя
    возможность использования C-интерфейса
    по-прежнему существует (для тех случаев, например, когда вам проще
    процедурно генерировать геометрию, чем моделировать её традиционным
    путём).
  

 Файлы в формате RIB, описывающие
    геометрию сцены, обычно имеют расширение (внимание!)
    *.rib. В нашем
    примере вы видели обычное текстовое представление этого формата,
    однако стандартом также предусматривается двоичное представление
    таких файлов. Такие двоичные файлы занимают гораздо меньше места и
    хорошо подходят для случаев, когда сцена не требует дальнейшей
    обработки и всё, что нужно сделать – передать файл рендереру. Как
    указано в спецификации формата, RIB изначально
    предполагался не как средство обмена геометрической и структурной
    информацией между различными системами моделирования и анимации, но
    как средство передачи данных от таких систем к рендерерам, то есть
    файлы такого формата не обязательно должны быть максимально
    удобными для импорта в программу-моделлер, но должны представлять
    максимум информации для последующего рендеринга.
  

 RIB является очень хорошо продуманным расширяемым форматом. Это
    сыграло большую роль в том, что, несмотря на свой приличный
    возраст, Renderman всё ещё опирается на RIB, время от
    времени добавляя новые возможности и команды – и сейчас, через
    почти что 30 лет со времени изобретения формата, мы можем
    использовать файлы данного формата c самыми
    современными версиями новых рендереров, задействуя новые
    возможности и технологии, о которых создатели стандарта не могли
    даже мечтать.
  

 Второй составной частью стандарта Renderman является язык Renderman Shading Language  или, в
    приблизительном переводе, язык закраски Renderman. Не в наших
    привычках пользоваться настолько корявым переводом, и потому в
    дальнейшем будем использовать общепринятую аббревиатуру - SL.
  

 Язык SL представляет из
    себя некоторое подмножество языка программирования С, которое
    позволяет нам описывать при помощи алгоритмов практически любые
    визуальные свойства материалов, присвоенных вашей геометрии,. Это
    значит, что мы не ограничены какими-то встроенными в программу
    моделями освещённости и стандартным набором процедурных текстур,
    как это сделано в очень многих рендерерах - в нашем распоряжении
    находится вся мощь современного языка программирования, специально
    адаптированного для этой задачи.
  

 Дабы избежать короткого замыкания в мозгах
    неискушённых пользователей Maya, подойдём к
    вопросу с другой стороны. В Maya ведь есть
    шейдеры? И в чём их отличие от шейдеров в Renderman?
  

 Ответим на первый вопрос, а заодно определимся с
    терминологией. Итак, шейдер – это некая программа на языке
    программирования, которая описывает визуальные свойства того или
    иного объекта (например, поверхности модели). В данный момент нам
    не так важно, на каком языке написан шейдер и каким образом он
    вызывается – главное, что мы знаем, как это сделано и как
    работает.
  

 Так вот с этой точки зрения майские материалы
    шейдерами не являются. Вы можете скомбинировать ноды в HyperShade в нужном порядке, получив тот или иной материал –
    но шейдера в результате вы не получите.
  

 Очень часто в литературе и разговорах встречается
    словосочетание “процедурная текстура”. Исходя из вышесказанного, и
    шейдеры, и материалы являются процедурными текстурами – в отличие
    от текстур непроцедурных, или говоря языком родных осин –
    картинок.
  

 Вообще говоря, идея процедурного описания
    визуальных и геометрических свойств  поверхности не являлась новой
    даже для 1987 года, в котором появился стандарт Renderman. Идея
    эта является простой экстраполяцией того факта, что при
    программировании на низком уровне мы ВСЁ РАВНО описываем и
    геометрию, и визуальные свойства объектов в виде неких алгоритмов
    (ключевое слово для программистов: OpenGL). Теперь
    же, когда мы поднялись на более высокий уровень и для рендеринга
    картинки уже не нужно писать больших и сложных программ (а
    достаточно нажимать большие кнопки с красивыми иконками)–
    оказалось, что процедурное описание закраски всё ещё остаётся
    полезным, поскольку является наиболее гибким способом такого
    описания. Процедурные текстуры обладают и другими неоспоримыми
    достоинствами, например, малым (по сравнению с обычными) размером
    файлов; отсутствием зависимости от разрешения получаемой картинки.
    Но несмотря на все преимущества подхода, до появления Renderman написание шейдеров носило в основном экспериментальный
    характер; именно Renderman сделал
    шейдеры полноценным индустриальным стандартом; язык написания
    шейдеров SL является, возможно, наиболее известным и
    распространённым среди других шейдерных языков.
  

 Как мы уже говорили, шейдер на SL - это программа
    на Си-подобном языке программирования, описывающая алгоритмически
    визуальное представление объектов, а если быть точнее – описывающая
    алгоритм расчета интегрированной освещенности и прозрачности для
    данной точки поверхности геометрического примитива. Для большего
    удобства в этом языке были сделаны некоторые изменения, например,
    были введены специальные типы данных, которые описывают цвет и
    позицию в трёхмерном пространстве; синтаксис языка и его
    стандартная библиотека процедур были упрощены, оптимизированы и
    дополнены по сравнению с оригинальным языком С для работы с такими
    типами данных; был веден набор глобальных переменных, несущих
    информацию о цвете источников света, положении и ориентации
    освещаемого сэмпла и так далее, существенно облегчающих
    программирование шейдеров.
  

 Простой шейдер на языке SL, реализующий
    металическую изотропную модель освещения поверхности, будет
    выглядеть так:
  
\code{code/ex1.sl}  

 Как можно видеть, любой более или менее сведущий в
    программировании (в особенности на языке С) человек может
    достаточно быстро научится писать данные шейдеры как вручную
    (многие студии и разработчики всё ещё предпочитают этот путь), так
    и с использованием специальных визуальных инструментов разработки
    шейдеров.
  

 При помощи шейдеров в Renderman можно
    контролировать не только модель отображения поверхности
    (surface shaders), но и влиять на её геометрию (displacement shaders),
    управлять поведением источников света (light  shaders),
    прохождением света через область сцены (volume shaders) и общим
    отображением информации в виртуальной камере (imager shaders):
  

  \gr{image005}
  

 Работа с шейдерами в SL также упрощена
    путём введения модели “чёрного ящика”. В переводе на человеческий
    язык это означает, что в каждый момент времени наш шейдер имеет
    дело с одной конкретной точкой в сцене и отвечает на вопрос “Что
    происходит в данной конкретной точке сцены”? Об этой точке шейдер
    знает всё: где она находится, какой цвет назначен геометрии в этом
    месте по умолчанию, какими геометрическими параметрами она
    обладает. Шейдер в такой модели представляет из себя “чёрный ящик”
    с некоторым набором “ручек” – вы засовываете исходные параметры в
    этот ящик, поворачиваете ручки в нужные позиции и получаете готовые
    данные, и так – для каждой точки в вашей сцене. Обратной стороной
    медали в данном случае служит тот факт, что в рамках шейдера вы в
    общем случае не имеете возможности обратиться к данным, которые
    относятся к СОСЕДНЕЙ точке этой же сцены, этого же полигона или
    шарика.
  

 Где-то там наверху я говорил вам, что в
    стандарте Renderman есть 2
    основные части? Я оговорился, их таки три, и на закуску я оставил
    самое интересное.
  

 Еще одной стороной стандарта, о которой мало кто
    упоминает,  является
    тот факт, что этот стандарт определяет не только форматы файлов
    которые применяются для обмена информацией между системами анимации
    и моделирования и  системой рендеринга, но и набор требований, который позволяет и
    другим разработчикам создавать различные рендереры, которые могли
    бы принимать подобные файлы.
  

 На самом деле,  стандарт никоим образом не
    указывает вам, какого рода рендеринг должен происходить и какого
    рода обработка должна производиться с вашими файлами. Ваш рендерер
    может быть рейтрейсером или использовать технологию сканлайн. Вы
    можете поддерживать Global Illumination,
    можете быть REYES (Renders Everything You Ever Saw), как prman, объёмным рендерером, гибридным, использовать A-Buffer, какие-то
    другие технологии или их сочетания – стандарт не оговаривает таких
    подробностей и  не
    ограничивает вас в деталях реализации. Всё, что нужно сделать для
    того, чтобы ваш собственный рендерер стал официально совместимым со
    стандартом Renderman – это
    выполнить некий набор специальных требований (описанный в
    спецификации стандарта и в книге Renderman Companion), а
    именно:
  
\begin{itemize}

\item поддерживать некоторое количество стандартных геометрических примитивов и понимать формат файлов RIB

\item поддерживать шейдеры во всём их разнообразии и, соответственно, файлы SL

\item поддерживать внутри себя иерархическую структуру сцены в соответствии со стандартом

\item содержать в себе стандартный набор из 15 шейдеров, также описанных в стандарте 

\end{itemize}

 а также делать некоторые другие, не настолько
    интересные и важные вещи. И это – весь список. Любые другие детали
    реализации движка рендеринга остаются на совести разработчика; в
    стандарте есть только небольшой список того, что было бы здорово
    иметь:

\begin{itemize}
 \item     Ray tracing
 \item      Global illumination
 \item      Level of detail
\item      Depth of field
\item      Motion blur
\item      Area light sources
\end{itemize}

 Подобная гибкость стандарта вкупе с его
    открытостью, продуманностью и массированным продвижением
    компанией Pixar не осталась незамеченной. Семена легли в
    благодатную почву всеобщего интереса к 3хмерной графике (области
    знаний на тот момент только развивающейся и новой, а потому вдвойне
    интересной), специальным эффектам в кино (помните – Terminator
    2... Jurassic Park…
    Как давно это было...) Добавим в коктейль отличный референсный
    продукт от самих Pixar – и получим
    воистину взрывоопасную смесь, которая немедленно
    сдетонировала.
  

 Вокруг стандарта Renderman немедленно образовалась новая ниша продуктов – рендереров,
    экспортеров из всевозможных систем анимации и моделирования,
    вспомогательных программ. Новичок в индустрии, стандарт сам {\it стал индустрией}. На
    данный момент существует больше десятка рендереров, являющихся
    совместимыми с Renderman (ссылка
    на постоянно обновляемый список будет приведена в конце главы);
    фактически не существует такого пакета 3D-моделирования
    который бы не выводил в RIB сам или при
    помощи плагинов.
  

 Более того, благодаря своей открытости и
    доступности Renderman вошёл в программу обучения многих
    американских университетов. На крупнейшем мировом форуме,
    посвященном компьютерной графике (я имею в виду, конечно же, Siggraph) Renderman’у посвящаются отдельные курсы, проходят
    собрания Special Interest Groups of Renderman
    и Birds of Feathers (не
    просите меня это перевести), на которых разработчики и пользователи
    стандарта и совместимых с ним продуктов встречаются, обмениваются
    новыми идеями. Renderman живет
    своей отдельной жизнью и пользуется огромной популярностью в
    студиях и среди непрофессиональных пользователей (благо, рендереров
    хватает на любой вкус, как высококачественных и дорогих, так и
    бесплатных с открытым доступом к исходному коду).
    Фактически, Renderman стал
    одним из столпов современной индустрии визуальных
    эффектов.
  

 Я очень хотел бы закончить наш краткий экскурс на
    этой мажорной ноте, но, как говорится, в жизни всё не так, как на
    самом деле.
  

 Историческое развитие индустрии компьютерной
    графики привело к тому, что Renderman не стал универсальным
    стандартом, которого придерживаются все и любые системы рендеринга.
    Это абсолютно нормальное явление, конкуренция хороша и нужна везде.
    Так или иначе, компания Pixar отказалась от роли технологического
    лидера и проповедника, сконцентрировавшись взамен на своей
    деятельности как анимационной студии (за что им огромное спасибо).
    Таким образом, компания прекратила продвижение стандарта Renderman, перестала выдавать лицензии на соовместимые рендереры
    и взамен стала продвигать тот самый референсный рендерер Photorealistic Renderman. Эра всеобщего благолепия и братства людей-цветов закончилась
    в августе 2002 года, когда Pixar подала в суд
    на разработчиков одного из конкурирующих рендереров,
    компанию Exluna, с
    обвинениями в нарушении патентного права. Таким образом,
    руководимая Стивеном Джобсом компания устранила одного из своих
    основных конкурентов на рынке Renderman-совместимых рендереров. Можно долго спорить, кто был прав или
    виноват в данном случае, но факт остаётся фактом – мир изменился
    навсегда, Renderman повзрослел.
  

 Ну вот, на мажорной ноте закончить не получилось,
    на минорной ноте обрывать историю - не хочу. Да и не нужно её
    обрывать, на самом деле, потому что на этом месте история
    заканчивается и начинается сегодняшний день. День, когда prman и стандарт Renderman  сам по себе имеют множество
    последователей по всему миру, и в том числе среди русскоязычных
    пользователей; день, когда технологии, описанные данным стандартом,
    нашли применение и признание как в зарубежных, так и в
    отечественных студиях. День, когда историю пишем мы.
  

 Не знаю, получилось ли у меня  на одном вдохе рассказать о
    стандарте Renderman. Мне
    очень хотелось рассказать о нем побольше; очень многое просто не
    влезло или не очень соответствует формату “книжки про Maya”.
    Я не рассказал вам многое из истории стандарта и продукта, я не
    приводил никаких сравнительных таблиц и не публиковал картинок и
    схем. Всё это можно найти в книгах и на ресурсах в Интернет, ссылки
    на которые я собрал в конце главы. Ну а теперь пришло время
    выполнить данное ранее обещание и объяснить, почему именно
    связку Maya-Photorealistic Renderman используют в своём пайплайне ведущие продакшн хаусы мира (не
    утруждая себя полным перечислением – вряд ли оно возможно вообще –
    укажем лишь ILM, Weta Digital, Disney, Sony Pictures Imageworks, Moving Picture Company, Framestore, Tippett Studio, Jim Henson Studios, наконец,
    сам Pixar – список уже можно назвать “места работы моей
    мечты”).
  

 Как только студия принимает решение использовать в
    своём пайплайне спецэффекты с использованием того или иного
    рендерера, к нему предъявляются некоторые достаточно специфические
    требования (в просторечии – “быть production-ready”):

	\begin{enumerate}

\item  Набор возможностей рендерера не должен
    ограничивать пользователя, это очевидно. Какие-либо ограничения на
    количество или качество входных или выходных данных недопустимы.
    Даже если вам кажется, что никто никогда не сделает сцену со 100
    миллиардами полигонов – вспомните Билла Гейтса с его знаменитой
    фразой о 640 килобайтах памяти, которых хватит всем (1981
    год).
  

\item                  Рендерер должен понимать множество типов
    входной геометрии. В современных условиях даже самый быстрый и
    качественный рендерер, оперирующий только полигонами, обречён на
    забвение.
  

\item                   Рендерер должен представлять широкие
    возможности настройки. Ничто так не радует TD (вы ведь
    знаете, что это такое? Technical Director – в
    просторечии, компьютерный разработчик спецэффектов), как мощный
    набор инструментов для баланса между качеством требуемого
    результата, скоростью рендеринга и требуемой для него
    памятью.
  

\item                   Более того, рендерер должен быть гибким.
    Лучшее доказательство гибкости рендерера – это когда его используют
    не по прямому назначению. Хороший пример – производство
    нефотореалистичной анимации (так называемый “картун” – cartoon animation) при
    помощи “фотореалистичных” рендереров.
  

\item                    Надёжность. Давайте посчитаем. 70 минут
    среднего полнометражного полностью 3хмерного мультфильма. Вы врядли
    работаете именно над таким проектом, но помечтать никто не мешает.
    Так вот, 70 минут или 4200 секунд. 24 кадра в секунду. Чуть больше
    100 тысяч кадров – и это только чистового рендерера, то есть с
    учётом проверочных рендерингов, внесённых по ходу изменений,
    раздельных рендеров по слоям и служебных рендеров (текстуры, тени,
    бейкинг другой информации) мы эту цифру можем запросто умножить на
    6. Кто-то прокричал “тридцать”? Мне нравятся ваше стремление к
    совершенству и ваши бюджеты, но мы останемся с нашей цифрой.
    Впрочем, вы таки подпортили мне настроение, да и цифра 6 мне
    сегодня решительно не нравится – поэтому давайте умножим на 7.
    700000 кадров. По часу, скажем, на кадр. 80 машино-лет непрерывного
    рендеринга. Так вот смысл наших расчётов состоит в том, что production-quality renderer не должен падать. Софта без ошибок не бывает, в особенности
    такого сложного и наукоёмкого, каким является рендерер – и тем не
    менее, ПАДАТЬ РЕНДЕРЕР НЕ ДОЛЖЕН. Каждое падение добавляет новые и
    новые перерендеринги к вашей задаче и забирает деньги (которых в
    бюджете и так мало) и время (которого до дедлайна вообще почти не
    осталось).
  
\item                   Надёжность. Вы не ошиблись и я не
    оговорился. Написать это во второй раз не помешает.
  

\item                   Производительность. Помните цифру
    наверху? 700 тысяч кадров. Которые вам нужно отрендерить на вашей
    старенькой ферме за полгода. И не стоит рассчитывать на закон Мура
    (“Мощность вычислительных устройств удваивается каждые 18 месяцев”)
    – в нашей индустрии действует другой закон, Блинна – “Вне
    зависимости от скорости компьютера, кадр считается одинаковое
    количество времени”. Как только вы проапгрейдите свои компьютеры
    – TD немедленно найдёт, чем занять их новые
    мощности.
  

\item                   Предсказуемость. TD должен быть в
    состоянии догадаться, насколько увеличится время рендеринга при
    добавлении того или другого элемента. Если вы добавили мелкий
    элемент в сцену и время обработки увеличилось вдвое – это не ваш
    выбор.
  

\item                   Последовательность. Ваш рендерер умеет
    рендерить все поддерживаемые примитивы с применением Motion Blur. В
    день X авторы программы добавили поддержку нового
    примитива, который пока что не понимает MB. В день X+2
    именно с этой проблемой вы столкнётесь в вашем проекте. Все
    “навороты” используемого вами решения должны понимать друг друга и
    взаимодействовать соответствующим образом – за исключением
    бессмысленных случаев – и, возможно, даже в этих бессмысленных
    случаях.
  

\item                 Качество результата. Мы поставили его в
    конце, и этот параметр иногда сложно измерить – но на самом деле,
    это самый главный параметр, самое главное требование, основа всех
    основ в рендеринге. Если вы делаете кино, то ваши картинки будут
    показаны на большом (на самом деле – на ОЧЕНЬ БОЛЬШОМ) экране, и
    каждый грязный и неправильный пиксель будет иметь размеры, которые
    можно будет определить при помощи большой деревянной линейки
    (такие, знаете, которыми так удобно размахивать, взявшись двумя
    руками). Любые артефакты, будь то плохой антиалиасинг, неправильная
    апроксимация геометрии, ошибки отсечения, полосы Маха –
    недопустимы. Более того, скорее всего вы делаете анимацию – а это
    означает, что также важно соответствие кадров друг другу во всех
    деталях. Неподвижные объекты не должны дёргаться, медленно
    движущиеся – прыгать; антиалиасинг должен быть правильным и
    одинаковым для объектов любого размера, находящихся на любой
    дистанции от камеры.
\end{enumerate}

 Ух! Объяснение у нас получилось очень длинное и
    очень простое – prman полностью
    удовлетворяет всем приведённым выше требованиям. А теперь сравните
    этот список с другим, относящимся к стандартному рендереру Maya.
  

 Убедил? Тогда продолжим.